Reports now include the hostname and username of the backup (for create, the
archive's own host/user; for repo-wide commands like prune, the local host/user).
borg monitor groups reports by (host, user, command, archive series) and reports
each distinct backup job independently, so several hosts backing up the same
archive series name to one repository no longer mask each other. New --host and
--user options restrict the output (alongside --name and --command); the JSON
entries expose hostname/username/command/archive.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

borg delete, borg undelete and borg transfer now publish a monitoring report as
the last action while the store is open (skipped on --dry-run), with host/user
defaulting to the local machine like prune. Stats record the number of archives
deleted / undeleted / transferred (plus considered/skipped and transferred
bytes). These appear as their own units in borg monitor (command=delete /
undelete / transfer).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Object names are plaintext and thus under the untrusted repository server's
control, but the reader treated their order as truth: iter_reports() yielded
objects in name order and the last one per job won. So the server could copy an
old, validly signed "success" report to a new, later-sorting name and shadow a
newer failure report for the whole --max-age window.

Two defenses:

- borg monitor now picks the latest report per job by the signed timestamp
  inside the report instead of by arrival order. This is the only defense
  available for unencrypted repos, whose reports are not sealed at all.
- The object name is bound into the HPKE aad, so a sealed report only opens
  under the name it was published as. Re-serving it under another name now
  fails loudly instead of silently winning.

Since every report's timestamp is parsed now (not just the winner's), a report
with a missing or unparsable time is skipped with a warning rather than
crashing the reader - the contents of an unsigned report are attacker
controlled. Skipping can only drop an entry, never mask a newer one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Tampering with a sealed report already fails the run, but the server could avoid
that entirely: delete the sealed report it can not forge and put an unsigned
"success" of its own in its place. That came back as trusted=False, which is
only a warning - so a compromised server could downgrade a failing backup into
something an operator alerting on errors alone would never see.

A monitoring key only exists for an encrypted repository, and such a repository's
client always seals its reports, so an unsigned report there can not be genuine.
Reject it like any other verification failure instead of reporting it as merely
untrusted. Unencrypted repos (no key configured) keep the old behaviour: their
plaintext reports stay readable, untrusted and warning.

Also fix the text output hint, which claimed an untrusted report meant the repo
is unencrypted - it can equally mean no BORG_MONITORING_KEY was set.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The body of an unsigned report is whatever the untrusted server chooses to
serve, but the reader took its shape on faith. A body that is not a JSON object
crashed borg monitor with an AttributeError traceback, a list where a string
belongs (e.g. "archive") crashed it with an unhashable-type TypeError when
grouping, and a report without a status was neither an error nor a warning -
so it silently counted as a success.

deserialize() now shape-checks every report: the fields the reader relies on
(command, time, status, rc) must be present and of the right type, the optional
ones (hostname, username, archive, archive_id, stats) must match their type if
present, and status must be one of success/warning/error. Anything else is
refused with a clean error. Reports from a real client always pass, so this only
affects bodies nobody signed.

An unparsable *value* in the time field is still tolerated (the report is
skipped with a warning, see the previous commit); this is about the shape.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>